Machine type communication (MTC), sometimes referred to as machine to machine (M2M) communication, is a form of data communication that involves one or more electronic entities (MTC devices) without necessarily requiring human interaction. MTC devices are mobile terminals (User Equipment (UE)) configured for MTC and they come in many forms in order to serve many different MTC applications and provide many different MTC services.
Generally, a service optimized for MTC differs from a service optimized for Human to Human (H2H) communications. Specifically, MTC is different to current mobile network communication services as it involves a different set of considerations to H2H mobile communications including, for example: different market scenarios, data communications, lower costs and effort, and potentially a very large number of communicating terminals with, to a large extent, little traffic per terminal.
Some examples of the types of applications and service types that MTC may be used to provide are listed in Table 1. The list in Table 1 is not exhaustive, and is provided as an indication of the wide potential application of MTC to provide an extensive and diverse range of MTC services.
TABLE 1Service TypeMTC ApplicationsSecuritySurveillance systemsBackup for landlineControl of physical access (e.g. to buildings)Car/drive securityTracking & TracingFleet ManagementOrder ManagementPay as you driveAsset TrackingNavigationTraffic informationRoad tollingRoad traffic optimization/steeringPaymentPoint of salesVending machinesGaming machinesHealthMonitoring vital signsSupporting the aged or handicappedWeb access Telemedicine pointsRemote diagnosticsRemoteSensorsMaintenance/ControlLightingPumpsValvesElevator controlVending machine controlVehicle diagnosticsMeteringPowerGasWaterHeatingGrid controlIndustrial meteringConsumer DevicesDigital photo frameDigital cameraeBook
One of the current requirements of MTC, defined in the relevant 3GPP standards (TS22.368), is the ability to send a so called ‘MTC device trigger’ from an MTC server to an MTC device, by which the network can trigger the MTC device to initiate communication with the MTC server. This MTC device trigger provides for a polling model which supports the many M2M applications for which polling from the MTC server to MTC devices is desirable. For example, polling is desirable for applications in which an MTC user wants to be in control of communication from MTC devices and/or does not want MTC devices to be able to access the MTC server arbitrarily. Further, even for applications where the MTC devices are allowed to initiate communications without being triggered by the server, there may still be a need for the MTC server to poll the MTC devices, for example, to interrogate them as part of a maintenance procedure.
A communication network supporting MTC must therefore be able to trigger MTC devices to initiate communication with an MTC server based on a trigger indication from the MTC server. Thus, an MTC device must be able to receive the trigger indication from the network, and be able to establish communication with the MTC server when the trigger indication has been received. In accordance with this, there are a number of different communication scenarios in which the MTC device may be required to receive a trigger indication including, for example: when the MTC device is offline (detached from the network); when the MTC device is online (attached to the network for signaling or user plane data), but has no data connection established; and/or when the MTC device is online and has a data connection established.
In order to provide for receipt of trigger indications when the MTC device is offline (i.e. detached), an MTC device should be able to listen for trigger indications even though it is not attached to the network, for example on a broadcast or on a paging channel. However, with non-attached MTC devices, the network has no definitive knowledge of the location of an MTC device (which may have moved since it last connected) and, accordingly, does not know in which cell (or group of cells) to broadcast the trigger message to ensure that the MTC device receives it.
One potential solution to this problem is for an MTC user (who does have knowledge about the location of the MTC device) to provide a Public Land Mobile Network (PLMN) with the necessary information on the location of the MTC device. Accordingly, based on the information provided to it by the MTC user, the PLMN can then broadcast a trigger indication in a relevant cell or group of cells. The MTC device, while not attached, may thus listen to the broadcast channel of the PLMN in order to ensure that any trigger indication is received.
The trigger indications may be broadcast using a Cell Broadcast Service (CBS) (e.g. as specified in 3GPP standard TS23.041) in which one or more Cell Broadcast Entities (CBEs) are connected into a radio network via a Cell Broadcast Center (CBC) that is under control of a mobile network operator. The mobile network operator may make an interface of the CBC available to a trusted 3rd party to interconnect their own CBE to the CBC of the mobile network operator. The MTC Devices are assigned a Unique Paging Identity (UPID) and are programmed to monitor a predetermined set of CB channel(s), even when they are not attached to the network. Accordingly, the MTC Server of the 3rd party is able to send CBS messages including one or more DPIDs, to specific MTC devices via the 3rd party CBE, in particular areas based on location information made available to the MTC server by the MTC user. The MTC trigger may also be broadcast in system information.
This method of broadcasting the MTC trigger within system information, or using a CBS, requires that the PLMN be provided with new location information, by the MTC user, for each move of the MTC device to an area for which there is a change to the cell (or group of cells) in which the trigger indication should be broadcast. This is a workable solution as long as the MTC user is able to provide the PLMN with the MTC device location information when required, and so is best suited to applications in which the MTC device does not move, or only moves very rarely (for example, gas and electricity smart meters).
Many MTC devices move only rarely (e.g. gas or electricity meters, when the owner of the meter moves house) and so new location information may be provided to the PLMN, by the MTC user, relatively easily. However, there are MTC applications (e.g. mobile vending machines) for which the corresponding MTC devices remain offline for long periods but move with such regularity that provision of the new location information to the PLMN, by the MTC user, becomes impractical or even impossible. In such scenarios, the MTC User may not even have an up to date location for the MTC device. Similarly, there are many other type of MTC Devices that may move, whilst offline, and for which upto date location information cannot be provided by the MTC user (for example, home based MTC Devices that move when the owner of the MTC device travels). Since these MTC Devices are offline (not attached) and the PLMN has no information about their location, the MTC devices cannot be sent a trigger indication by the MTC server unless the PLMN broadcasts the MTC device trigger indication in all of the cells of the PLMN to make sure that the MTC device is guaranteed to receive the trigger indication. However, broadcasting in all cells is impractical as it would be very inefficient, and may even be technically impossible.